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SUMMARY 



UTS is today a major competitor in the field of multiprogrammed/timeshared operating 
systems for medium- and large-scale digital computers. Its capabilities compare 
favorably with or exceed OS (IBM), GECOS (Honeywell), TOPS-10 (DEC), EXEC 8 
(Univac), VMOS (RCA), MCP (Burroughs), Kronos (CDC), etc. A recent benchmark 
was extraordinarily comprehensive, consisting of 170 batch jobs, including major multi-sort 
business data processing jobs as well as student FORTRAN compile-and-run jobs, together 
with 40 on-line terminals. In this test, which ran nearly two and a half hours, UTS on a 
Sigma 9 was the price/performance winner over an IBM 370/155, a CDC 6500, a Univac 
1106, and a Honeywell 6070. The important capabilities of UTS include the following: 

Multiprogrammed batch processing with resource control 

Comprehensive on-line (timesharing) services 

Peripheral symbionf (spooling) system for both batch and on-line users 

Remote batch terminal processing 

File management system for tape, pack, and RAD, including consecutive, 

random (direct), and keyed (ISAM) files 

Extensive reliability features, including automatic system recovery and 

error logging and displays 

On-line peripheral diagnostics 

Automatic system failure analysis 

On-line system debugging and performance measurement services 

Current projects will add the following important features to the system for field delivery 
before the end of 1972: 

Utilization of the full 512K core memory capability of the Sigma 9 

ANSI format tape processing, including full label control 

Disk pack system (no RAD) for lower price entry 

The addition of EASY, the GE Mark II style of terminal command language, 

and TEXT, an ATS-like text editing and printing service 

Those features which give UTS its unique place in the industry are the following: 

The extensive timesharing facilities (perhaps the best in the industry) 
The complete file compatibility of the batch and on-line environments 
The availability of all batch services to on-line users 
! The use of the virtual memory map to use core memory economically, 
especially via the 40 shared processors 
The speed and reliability of the system 
The software and hardware maintainability features 
The extensive library of useful processors and programs supplied by both 
Xerox and the user group. 

Proven performance in environments including business data processing 
as well as timesharing/scientific applications. 

Absolute security protection of files and programs from accidental or 
malicious misuse. 
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1 . GENERAL DISCUSSION 

This section summarizes those system facilities and features which are common 
to ail operating environments: multiprogrammed batch, on-line terminals, and 
remote batch jobs. 

1.1 ON-LINE/BATCH COMPABILITY 

Because multiple batch jobs and on-line user sessions are treated uniformly as 
users of the system, complete compatibility exists between the two environments 
for both program execution (any program may be run either on-line or from re- 
mote or central site batch inputs) and of the files used, created, or updated, 
including access to all peripherals (tapes and private packs as well as printers 
and card punches) by on-line users, assuming they are authorized for such access. 

1.2 VIRTUAL MEMORY 

Via the hardware memory map and software management routines, core memory 
is efficiently utilized; it changes as necessary from moment to moment, allowing 
all momentarily inactive memory to be available to the system for the highest 
priority jobs. 

Use of the map to share the code portions of reentrant processors among concurrent 
users achieves savings in core, which results in added throughput. In conjunction 
with virtual memory management, the UTS swapper allows the total size of all 
running programs, both batch and on-line, to exceed the size of real memory by 
orders of magnitude. 

1.3 UNIT RECORD DEVICE SPOOLING (SYMBIONTS) : 

Unit record devices such as card readers, line printers, card punches, plotters, 
and other devices so specified at SYSGEN time will be spooled via disk pack or 
RAD by the UTS "symbiont" routines. This buffering of I/O to the low-speed de- 
vices via the high-speed RAD or pack smooths the peaks and valleys of device- 
loading and provides for multiple simultaneous logical streams of I/O to these 
devices in the multiprogramming/terminal system. 

1.4 DEVICE INDEPENDENCE 

Sources and destinations are controlled by I/O assignments at execution time, which 
extends to the on-line terminals as well as peripheral devices and files. Standard 
defaults select the normal input and output units as either card reader and printer 
(if batch) or the terminal (if on-line) without any action by the user. 
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1.5 COMPREHENSIVE DEFAULT CONVENTIONS 

System defaults are provided - and are dynamically changeable by installation 
management - for limits, I/O assignments, processor options, etc., making the 
required JCL and terminal commands especially simple for standard operations 
and job setups. 

1.6 ACCOUNTING/MACHINE RESOURCE CHARGING 

The UTS accounting facility is especially complete. The wide assortment of 
statistics accumulated during job operation are reported both to the user and to 
a system file for installation accounting accumulations. The installation may 
assign charge values to each of the machine resources used, and the system will 
calculate and report the total cost accordingly. In addition, facilities are 
available to allow each installation to augment system accounting with routines 
unique to its particular needs. 

1.7 CENTRALIZED ERROR MESSAGE FILE 

The text for system and processor error messages are carried in a standard system 
file so that they may be easily changed to satisfy individual installation needs. 
Clear text messages are provided rather than the harder-to-interpret code numbers. 
Cade numbers are provided whenever a corresponding message is not on file. How- 
ever, they may be; inserted on-line using EDIT. 

l..a SYSTEM SERVICES^ 

System services are detailed in Section 6 on User Control. Internal services in 
the form of requests to the monitor via CAL instructions are available to both 
batch and on-line programs without limitation. Broadly speaking, they may be 
categorized as folio ws^ 

Item Types 

I/O- ?snues*5 fbr files or devices 35 

Debugging services 6 

Memory management 9 

Control operations (traps, interrupts) 8 

Program management 5 

Privileged services 7 

Miscellaneous services 10 

ll* MODULAR 1 IMPLEMENTATION 

LLT5- has a" well -organized and highly modular internal organization. The 
broad capabilities of the system allow many of its services to be provided 
by slaved mode programs - some running as GHOSTS - which are simple 
tec extend and debug as well as easy to add to the system, since a SYSGEN 
is not required. More than 40 processors supported by the UTS Section 
(which does not include any language processors) fall into this category. 
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The resident monitor is itself highly modular, as shown by its ability to 
extracr significant portions and debug them separately under simulators, 
as discussed in Section 13 on Maintainability and Extendability. Major 
segments of the resident monitor cover functional sections as follows: 

a. Basic I/O enqueueing and device handlers 

b. Terminal I/O management 

c. Symbionts and cooperatives 

d. Scheduling and swapping 

e. Memory management 
f.. Job step control 

g.. File management 

h. Load-and-l ink services 

i. Batch debugging commands 

j. Initialization 

k. Operator communications 

I. Accounting and performance monitoring 

m. System recovery 

n. System debugging 

o. Error logging and diagnostic program interfaces 

p. Multibatch scheduling 

q. Remote batch terminal management 

r. File granule allocation 

An example of the modular nature of the system and the strength of the 
interfaces occurred with the COO release. In this case, IOQ and the 
handlers were extensively revised to add device (pack) pooling. This 
Feature, after test under BPM, was inserted in UTS without error. 

"LTO EXECUTION SCHEDULING 

UTS provides a multilevel scheduler which uses 30 states that provide 
separate execution time priorities for external interrupts, terminal input 
and output interactions, file I/O, and compute-bound programs. This 
unique scheduler assures fast response to interactive users while, at the 
sometime, providing for an efficient multiprogrammed mix of I/O and 
compute-bound programs. The scheduling states also control the swapping 
algorithm for the same purpose, in particular providing a meaningful 
outswap ordering. The scheduler adapts efficiently to the actual environ- 
' rrrent whether batch only, interactive terminal only, or a mixture. 

UTT EXITCONTROL 

A Facility to allow a processor to acquire exit control in the event of any 
termination of the program, including inadvertent line disconnect or pro- 
gram abort for whatever reason. 
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2. MULTIBATCH PROCESSING 

UTS provides up to 16 concurrent batch processing partitions and guarantees 
that the total resources, such as tapes, private packs, core, etc., used by 
active partitions do not exceed the physical resources of the machine and 
the limits set by the installation manager. UTS classifies jobs dynamically 
into one or more of the 16 partitions depending on the resources required and 
the stated resource ranges of the partitions. Each partition, through its re- 
source ranges, represents a job class; however, UTS is unique in that it can 
and will run - in priority order - the job class for which resources are avail- 
able. This feature results in greater than usual throughput when jobs are 
submitted in an arbitrary manner. Conversely, critical jobs may have their 
resource requirements and priorities established in such close match to a 
partition class that immediate execution of critical jobs is assured. 

Partition definitions in UTS act as a screening process for job selection and 
do not define a fixed boundary partition in the traditional sense. Jobs acquire 
core dynamically as needed up to the specified limit. Any excess core is 
available for running other jobs. Batch jobs are not core-resident from start 
to finish but are scheduled and swapped as system load dictates, which 
assures maximum system utilization consistent with response time considerations. 
Resources may be released by a job at each job step, e.g., tapes unused in 
subsequent steps. 

The installation may define a priority increment to be used to increase the 
priority of bypassed jobs, thus giving them credit for longevity in the queue. 
Special treatment is accorded an F priority job, i.e., it is guaranteed to be 
the next job to be selected, depending only on the availability of the re- 
quired resources. 
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3. ON-LINE (TIMESHARING) CAPABILITIES 

3.1 ON-LINE BATCH COMPATIBILITY 

The total compatibility between batch and on-line programming mentioned 
in Section 1 means that all the programs and all the monitor service functions 
(CALs) are available on-line. While all programs will run on-line, the 
results may not be aesthetically pleasing if the program is not "interactive", 
i.e., if it does not assume that an intelligent person is available to answer 
questions and supply corrections. In the lists of on-line services listed below, 
only "interactive" programs are discussed. 

3.2 SERVICE PROCESSORS 

Processors which are of special importance to the on-line user are as follows: 

BASIC Programming language for small -to-medium 

arithmetic problems 

FORTRAN Comprehensive algebraic programming language 

METASYMBOL Sophisticated machine language assembler 

APL Functional programming language for science and 

business 

TEXT ATS-1 ike text editing and printing 

TEL Terminal command executive 

PCL Combined utility package for information transfer 

FDP FORTRAN debug package 

DELTA Machine language symbolic debugger 

EDIT Text editor 

LINK Program loader 

Terminal Interactive manager for business data: updating, 

Manage retrieving, generating reports 

COBOL Business language compiler 

EASY GE Mark II— I ike access to FORTRAN and BASIC 

GPDS General purpose discrete simulator 

CIRC Circuit analysis: DC, AC, and transient 

3.3 ON-LINE DEBUGGING (DELTA) 

; The DELTA on-line debugger is a particularly useful aid that may be used to 

advantage with any program, including FORTRAN and COBOL compilations, 
though it is especially designed for machine language. Symbol tables are 
available directly from the source code. Line-at-a-time assembly of machine 
language, instruction breakpoints, data value-change breakpoints, instruction 
traces, and transfer traces are included. A variety of conversion routines are 
easily invoked for terminal Input and output. 

3.4 ON-LINE FORTRAN DEBUGGING 

An exceptional facility for debugging of FORTRAN programs on-line or in 
batch is provided via the FD? library language. Breakpoints and displays 
are provided using the statement numbers and symbols of the source program. 
Automatic debugging is provided, including checking of routine calling and 
receiving sequences. 
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3.5 CENTRALIZED UTILITIES (PCL) 

A single comprehensive processor (PCL) that may be used in either batch or on-line 
environments replaces the usual proliferation of utility programs. Transfer 
of files in any system format is accomplished between any two devices via 
this easy-to-use command language. Format conversion and record selection 
may be specified and files may be concatenated or split. 

3.6 META-ASSEMBLER AND LINK-EDITING LOADER 

The:METASYMBOLassembler is procedure-driven according to definitions 
supplied by the user, allowing assemblies not only for Sigma equipment but 
for foreign machines. The loader complements the assembler with an unusually 
wide-ranging capability which, through the Sigma standard object language, 
eases the burden on compilers. 

3.7 EASY 

A GE Mark II protocol access to FORTRAN and BASIC is provided through use 
of a general command processor facility which allows an installation to define 
additional command processors (e. g., CO, TEL). 
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4. REAL TIME 

Although full real-time services cannot be claimed for UTS in the established 
SDS sense, it has substantial real-time capability by virtue of its underlying 
design. The I/O enqueueing routines and device handlers are nearly identical 
to those for RBM, our most successful real-time system. The file management 
system had its genesis in and is compatible with BPA/\/BTM, our other real-time 
system. Throughout the design of UTS, real-time-oriented principles were 
followed in table design and coding practices. Recent measurements of monitor 
Inhibit time, the main limitation on real-time response, have shown the majority 
of inhibits to be less than 350 psec. The few inhibit paths remaining at 750 psec 
and above are considered correctable anomalies rather than flaws in the basic 
design. 

UTS still lacks the formal real-time service CALs which allow monitor-supervised 
connection to interrupts although a specification was prepared for these services 
in 1970. Certain of the more difficult real-time services are inherently easier 
in UTS than in batch processing systems because its built-in swapping mechanism 
obviates special requirements for checkpointing the background in order to 
introduce nonresident real-time tasks; recovery of real-time tasks would 
similarly be a natural extension in UTS. 

The strength of UTS in real-time design and capacity is indicated by current and 
projected use: one real-time UTS configuration will be installed for CDC of 
Canada in mid-August 1972, with two other scheduled for later in 1972, one 
at Vandenberg Air Force Base and the other at Lockheed's Sunnyvale facility. 
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5. TELEPROCESSING 

Compatibility of terminal access with file and card reader/printer access 
has been discussed in Section 1. It is central to UTS teleprocessing services, 
making them more like the advanced TCAM of IBM than the older TAM 
services. 

5. 1 TERMINAL COMMUNICATION ACCESS METHODS 

Excellent terminal communication access routines provide support for a wide 
range of Teletypes (including all ASCII coding terminals) and 2741 -type type- 
writers (APL and standard keyboards; EBCD and selectric code sets), and CRT 
terminals. The UTS installation at UCI is using a dozen or more different 
types of terminals 

A unique feature is type-ahead (input message queueing), which allows a 
user to continue inputting commands without having to wait for the next 
computer prompt. Commands typed-ahead are synchronized with program output 
which assures a clear and meaningful output identical to nontype-ahead in 
form. 

Efficient COC buffering techniques provides this support with extremely low 
core storage requirements (four words/terminal), including output message 
queueing asynchronously with respect to the user program. 

Automatic page headings are provided, with formatting control over both 
page width and length. 

Simple line-editing commands for erasing characters and lines are available 
with the handling routines and thus are available to all programs and 
processors. 

Both half- and full-duplex paper tape input and output are supported from 
on-line terminals. 

Untranslated input and output is provided via a "transparent mode", which 
allows preparation of paper tapes for milling machine control and control 
over special devices, such as plotters and vector-generating CRT displays. 

A single program may control many terminals via the shared processor 
mechanism. The system automatically provides separate context areas for 
each terminal, thus vastly simplifying the programming problem for such uses, 
since the processor need act only as if it were dealing with a single terminal, 
i.e., no submonitoring is required within the processor. These processors 
may be written in any language - FORTRAN, COBOL, etc. Further, the 
system does not require that the processor be shared in order to operate many 
terminals, although system efficiency is increased thereby. 
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Prompt characters, if specified, are automatically supplied for each program 
read. A unique prompt has been chosen for the terminal executive and for each 
processor function to insure easy user identification of the requestor. 

Tab simulation is provided if desired, with explicit control over the choice of 
spaces or tabs for the reading program and the logical beginning point of the 
carriage. 

Miscellaneous other controls restrict input to upper case, allow input of 
lower case characters from Teletypes lacking them, provide for control 
transfer to the executive, acknowledge the presence of the system, allow re- 
typing of the current input. All terminal control modes can be established by 
use of control keystrokes or by the program using CALs. 



5.2 REMOTE BATCH 



The following lists the features and capabilities of the RBT support in the 
current (COO) release of UTS, which has been in the field since late May of 
1972. Extensions are planned as listed under the heading IRBT in Section 15 
for delivery in the second quarter of 1973. 

All system facilities available to local batch jobs are available to 
remote batch jobs. 

No modifications need be made to a job to run it from an RBT. 

Printed output is automatically sent when ready without operator 
intervention. 

Terminals can be operated in either the attended or unattended mode, 
i.e., with or without an operator. In the unattended mode, the terminal 
is disconnected if transmission errors forbid communication. 

Workstations are authorized by the system manager dynamically with 
SUPER, which also allows him to define a maximum priority for input 
jobs and the right to use the system account. 

Half- and full-duplex switched and unswitched communication lines are 
supported. 

The remote operator may defer output of files and request that output 
later. 

The remote operator may send and receive messages to and from the 
central site operator. 

The remote operator may delete his input and output files and abort 
his running jobs. 

The remote operator may obtain the status of any or all of his files. 

The remote operator can adjust the parameters (e.g., paper size) 
of his peripherals. 
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Either the remote or central operator can switch output files 
from one workstation to another or from an RBT to the central 

site. 

The complete format control capability of the remote printer 
is supported. 

Central site batch or on-line jobs may direct their output to 
a remote batch workstation. 

Form control is supported. The remote operator is informed 
of forms changes and can control registration. 

Input decks too big for the card hopper may be sent in shorter 
segments. 

Output files currently printing can be suspended by the remote 
operator; they can then be deleted, restarted either at the 
stopping point or the top of the form, or saved for later output. 
While an output file is suspended, jobs may be entered into 
the system. 

A simple procedure is provided to recover from all transmission 
errors, and no output is ever lost even in the case of complete 
device failure at the remote site. 

Full error checking is done on all control commands from the 
remote site; "message files" inform the remote operator of errors 
in his jobs and remote control commands. 

The message file provides a record of all jobs submitted by the 
workstation and their status, if requested. 

Remote batch may be added to a UTS system simply by defining 
remote batch devices during SYSGEN. 
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6. USER CONTROL 

6.1 JOB CONTROL LANGUAGE 

A batch job communicates its requests by means of the Job Control Language 
(JCL), a consistent language that allows for parameter sequence independence. 
UTS JCL is a compatible superset of BPM JCL. Monitor control commands 
written in this JCL are processed by CCI and provide the following functions: 

a. Specify resource requirements. 

b. Execute conditional job step. 

c. De-allocate resources. 

d. Send messages to operator. 

e. Assign a user's logical I/O (DCB) to a file or physical device. 

f. Provide heading information for the listing device. 

g. Set/reset pseudo sense switches. 

h. Specify debugging control commands. 

i. Modify existing load modules. 

j. Allows for reading of nonstandard binary cards. 

6.2 TEL 

TEL is a command processor that is the principal terminal language for UTS. 
TEL commands provide the following functions: 

a. Composing program and data files. 

b. Assembling and compiling programs. 

c. Linking object programs. 

d. Loading programs in any language and initiating their execution. 

e. Initiating debugging operations. 

f. Managing and backing up files. 

g. Submitting, status checking, and canceling batch jobs, 
h. Calling subsystems. 

?. Interrupting, continuing, and terminating execution. 

j. Logging off. 

k. Changing the log-on password. 

I. Checkpointing on-line sessions. 

m. Assigning I/O devices and DCB parameters. 

n. Determining on-line user status. 

o.« Listing a file directory. 

p. Listing system load parameters. 

q. Setting simulated tab stops. 

r. Obtaining terminal status. 

s. Changing terminal status. 

t. Changing terminal type. 

u. Changing terminal platen size. 

v. Sending messages to operator. 

w. Printing or punching output. 
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6.3 MONITOR SERVICES 

6.3.1 The debugging facilities of UTS are quite extensive. On-line users may 
call on DELTA when a program is loading or after execution begins. 
Although it was designed for use in debugging machine language programs, 
DELTA may also be used to debug programs written in FORTRAN, COBOL, 
or any other language. A special FORTRAN Debugging Package (FDP) 

is available. Postmortem dump and conditional snapshot dumps commands 
are available to facilitate batch debugging. If desired, they may be used 
on-line. 

6.3.2 Memory management services are available to allow for dynamic allocation 
of memory. User programs may get and release common, dynamic, or 
virtual pages. Memory protection may be increased by a user on any page 
by the user. 

The Change Virtual Map routine allows certain processors and privileged 
programs to examine, display, or change data portions of real physical core, 
especially the resident monitor. 

6.3.3 Trap control is provided for all users to transfer control to a trap routine for 
designated traps. An interval timer trap is available via M:STIMER and a 
console interrupt routine may be specified via M:INT. 

6.3.4 Remote Job Entry (RJE) is available to an on-line user through a TEL command 
or use of the M:JOB procedure call. Files may also be submitted for printing 
or punching. 

6.3.5 Program segmenting facilities are available by means of an explicit M:SEGLD 
procedure call within the program or use of the REF/BREF options on the LOAD 
command. This will automatically insert the M:SEGLD code whenever there 

is a branch type instruction to a DEF in a higher segment (BREF mode) or 
wherever there is an expression involving a DEF from a higher segment (REF 
mode). 

6.3.6 Inter-program communication may be effected through use of M:LINK and 
MiLDTRC procedure calls. Communication is accomplished through the general 
registers or common dynamic storage. 

Privileged programs may also initiate any processor in the system account as a 
ghost job through a procedure call within the program. 
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6.4 CATALOGUED PROCEDURES 

Through Its BATCH command, UTS includes a catalogued procedure facility, 
which may be used by on-line terminals to submit jobs (RJE) or by batch 
jobs themselves to spawn other batch jobs. Each call submits one or more 
jobs which may be independent or order-dependent on each other through 
the LIMIT command ORDER parameter. The current version does not include 
parameter substitution. The procedure may be nested indefinitely, i.e., 
catalogued procedures may themselves include calls to execute other 
catalogued procedures. The facility is heavily used to submit SYSGENs, 
regression test jobs, and the Engineering Department's analysis programs, 
run during the third shift. 
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7. OPERATOR CONTROL 

7.1 OPERATOR CONSOLE MESSAGE FORMATS 

Four classes of messages are printed in different formats on the operator's 
console in order to provide functional and visual separation. These formats 
are outlined below: 

a. Messages without tabs are for operator's reference at a later time. 
They are typed at the left margin. Examples are the following: 

id:ON 

id:OFF 

JOB acct, name, id, priority 

b. Messages preceded by a single tab are for symbiont operations. 
With normal tab setting, they are positioned one inch to the 
right of the left margin. Examples are the following: 

_Syyndd ACTIVE 
_Syyndd NOT ACTIVE 

c. Messages preceded by two tabs either concern specific users or 
are generated by batch or on-line users. (AH terminals logged 
into the system have the capability of sending messages to the 
operator's console.) With normal tab setting, these messages 

are positioned two inches to the right of the left margin. Examples 
are the following: 



id 
id 
id 



user message 

ndd DISMOUNT AND SAVE reel numbei 

MOUNT ndd, reel number 



d. Messages preceded by four tabs are for operator actions related 

to physical devices. With normal tab setting, they are positioned 
four inches to the right of the left margin. Examples are the fol- 
lowing: 

__LPA02 MANUAL 
CRA03ERROR 

The operator may cancel the printing of any message by depressing 
the BREAK key. 
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7.2 OPERATOR FUNCTIONS 

7.2.1 Job Control 

Key-ins are available to cause an error exit from a job step or abort a job 
in progress. 

7.2.2 Symbiont Control 

The operator has a variety of commands providing for symbiont control. The 
operator may initiate or suspend activity on any symbiont device, including 
remote batch terminals. Both forms control and the ability to delete or change 
the priority of a waiting input or output file is provided. 

7.2.3 System Control 

The operator may control the maximum number of batch or on-line users 
allowed in the system and may also force an immediate and orderly shutdown 
of the system. Many other system control functions are available through the 
primary operator's console if CONTROL is initiated as a ghost job. These 
capabilities are normally provided by means of a Teletype adjacent to the pri- 
mary console. Section 8 discusses these capabilities in detail. 

7.2.4 Operator-User Communication 

The operator may send a message to an on-line user or a remote batch workstation 
as well as establish a broadcast message for all on-line users or all remote batch 
workstations. Through use of the INT key-in, the operator may cause control of 
a user program to be transferred to a console interrupt routine. 

7.2.5 Peripheral Device Control 

Hardware errors requiring operator intervention are reported at the operator's 
console. The operator can cause an error status to be returned, a retry opera- 
tion to be performed, or may choose to continue as before. Errors requiring 
an operator response will periodically prompt the operator (every 20 seconds) 
with an appropriate message to insure that the error condition has been brought 
to his attention. 

7.2.6 Removable Volume Control 

The operator may premount or respond to specific mount requests for magnetic 
tapes and private disk packs. In the case of disk packs, he may also indicate 
whether the pack is to be shared or used exclusively by a specific user. Un- 
satisfied mount requests are repeated every 20 seconds to insure that the opera- 
tor has been notified. 
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7.2.7 Secondary Storage Control 

The operator is informed of critical secondary storage conditions whenever 
available space fails below a threshold established by the installation. The 
operator can cause inactive files to be backed up on tape to regain file 
space. 

7.2.8 Information Display 

The operator may display system information regarding tape usage, private 
pack usage, job status, and symbiont file information. Output for large 
displays may be directed t^ the line printer or the operator's console. 
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8. INSTALLATION CONTROL 

8. 1 ON-LINE INSTALLATION MANAGEMENT 

The programs that allow the Installation manager to control his installations 
are available from on-line terminals as well as through batch. These programs 
may be accessed from several terminals to provide separation of functions 
usually crowded onto a single operator's console. The El Segundo installations 
of UTS use two consoles. One covers the device error and recovery messages, 
logs jobs on and off, and provides tape mounting requests, while the other 
console is used for installation management functions as reviewed below. 

Since the management functions may be accomplished through batch jobs or on 
the operator console using ghost jobs, small batch-only UTS systems do not re- 
quire COC terminal hardware. 

8.2 SYSGEN 

The installation manager defines the profile of his system through the SYSGEN 
process. Through a process called PASS2, he specifies the hardware configura- 
tion and a number of parameters to tailor the system to his specific requirements. 
Most of the parameters specified at SYSGEN may be adjusted during system 
operation through the use of CONTROL to dynamically tune the system. The 
PASS2 process requires less than one minute to define the target system; all 
that then remains to be done is to load the UTS monitor and its overlays and 
those processors which reference symbolic locations within the monitor. The 
entire SYSGEN process, including the writing of the bootable system tape, 
can be accomplished in less than 30 minutes. 

8.3 CONTROL 

The CONTROL processor provides control over system performance. It may be 
run as a batch, on-line, or ghost job, though normally it is run on-line. 
CONTROL may be used to display or change more than 80 system parameters 
as wellas to redefine partition attributes of any of the multibatch partitions. 
It is the tool of the installation manager, comprising most of the operational 
control functions that would otherwise be performed by the operator. In this 
fashion, an on-line terminal serves as a secondary operator's console, allowing 
the primary operator's console to be used exclusively for basic operator functions. 
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8.4 UTSPM 

UTSPM performs the five following functions: 

-':. a. Displaying selected performance data on-line. 

b. Creating a statistical base of performance data which may 
be referenced to create a report. 

c. Creating a history file of performance data by collecting 
the data at specified intervals. 

d. Referencing one or more history files to generate a 
performance measurement report and to create chronological 
and sorted "snapshot" records of performance data. 

e. Referencing the statistical base to provide a report covering 
the interval from the time of the base creation to the time 
of the report. 

8.5 SUMMARY 

The SUMMARY processor provides a global view of UTS performance by 
formatting and displaying the statistical data collected by UTSPM. 

8.6 SUPER 

SUPER is used to authorize users' entry to the system and their access to 
available resources. A unique feature of SUPER is the ability to define 
an auto-call processor that is to be automatically associated with the on-line 
user at log-on time, which allows special terminal protocols such as those 
provided by EASY to be invoked automatically without the request of the 
user. 

8.7 RATES: MACHINE RESOURCE USAGE CHARGING 

UTS measures the usage of resources by each job - CPU time, pages, cards, 
core use, I/O requests, console minutes, tapes used, etc. At the end of the 
job, a "rate" table is accessed which contains multiplying constants. By 
applying the constants to the measured usage, a gross "charge units" number 
is calculated which is reported to both batch and on-line users on the summary 
supplied at job or session end. It is intended that a simple constant be used to 
transform charge units into charge dollars. A default set of charge rate tables 
is derailed in the UTS System Management Reference Manual, 90 16 74 , de- 
signed for 1,000 charge units to the penny. 

An additional feature of the UTS charge scheme allows up to eight separate 
rate tables to be assigned to different classes of users. The default supplies 
one for batch users and one for on-line. Further, the tables may be changed 
dynamically via a processor called RATES to provide differential charging, 
say by time of day - prime shift versus nonprime. 
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9. FILE MANAGEMENT 

9.1 GENERAL DESCRIPTION 



UTS includes a comprehensive file management system that is 
compatible with BPM/BTM for files carried on RADs , disk 
pack (both public and private), and magnetic tape. The 
following three organizations are included. They are 
equivalent in function, although different in name, to the 
offerings of other manufacturers. 

Random (direct) 

A contiguous pre-allocated set of 512-word granules 
accessed by relative granule number. Content is managed 
entirely by the user program. 

Consecutive 

A collection of variable- length logical records physically 
blocked into granules by the system. Access is tape-like: 
sequential, forward, reverse or spacing. Allocation is 
dynamic, and is limited only by the size of physical devices 
on the system. Control information is carried with the 
data blocks for fast access to this heavily used file 
organization. 

Key- indexed (ISAM- like) 

A collection of variable-length logical records, each of 
which has an associated key (name) . Access is either by 
key or sequentially or a ~m±ztvriz of the two. A tiered tree 
index provides for fast access by key to any record (for 
example, the file may be positioned using a keyed read, 
then read sequentially). Allocation is dynamic, limited 
only by the size of physical devices on the system. A 
program coded for consecutive files may access keyed files 
sequentially without program change. Keyed files may be 
created with records supplied in any order, although the 
storage packing will be more efficient if they are supplied 
in sort order. Any copy operation or backup and restore 
compacts the file to its most efficient storage format. 
Sequential access is also improved if the file is created 
in sorted order. 
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9.2 FILE ACCESS INDEPENDENCE 

Access methods are upward- compatible, i.e., a program which 
uses sequential access may read a keyed (ISAM) file without 
program change. This means, for example, that the editor 
can use keyed files for the power of their update capability 
and then pass this file to a processor, say COBOL, which will 
access it sequentially. The file need not be copied in order 
to remove the keys from the data. Thus the sequentially 
reading COBOL need not be aware of whether its inputs come 
from file (keyed or consecutive), from the card reader (via 
the symbionts) , or from an on-line terminal. 

9.3 AUTOMATIC FILE ALLOCATION 

Space on secondary storage is automatically allocated to files 
as the need arises (automatic extends) . No preallocation or 
extension specifications are required on the part of the user 
except for RANDOM files (direct) . This centralized pooling 
of secondary storage for consecutive and keyed files makes 
for especially efficient use of storage when compared to 
preallocation of space at file creation time. 

Statistics of use support the efficiency of the automatic 
granule-at-a-time allocation. A recent study of the sizes 
of files on the El Segundo Sigma 7 T machine under UTS shows 
that, of 6000 files, 50% used two or fewer granules (512 words) 
and an additional 20% used three to five granules . 

9.4 FILE SECURITY 

Access to user files is controlled through both passwords and 
explicit authorization lists of users who may read and may 
write in each file. Automatic file backup facilities secure 
the files against disaster, and automatic purging of files 
is accomplished using creation, backup, expiration, access, 
and modification dates carried with each file. 
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10.0 PERFORMANCE 

10.1 MONITORING AND TUNING 

UTS provides a significant set of performance tuning and monitoring services via the 
processors CONTROL and UTSPM. SUMMARY provides for performance data reduction 
presenting averages, histograms, and cross-correlations of the data. These tools are 
described in Section 8. 

10.2 TEXAS BENCHMARK 

A recent benchmark run for the University of Texas provides a comparison between UTS 
and the machines and operating systems of major manufacturers. The benchmark was of 
extraordinary completeness, covering the business data processing applications of the 
university as well as student and research problems. The more than 170 jobs included 
in the fast were submitted from remote batch terminals and at the central site. Thirty- 
eight TXS simulated lines were run concurrently using APL and BASIC and interacting 
once each ten to fifteen seconds, a particularly heavy rate. The 40-terminal on-line 
load was completed by University of Texas personnel at two other terminals doing timing 
and testing runs in a variety of languages. The batch stream, multiprogramming in four 
simultaneous streams, was unusually comprehensive. Several sorts, some on tape and 
some on pack, were included. One particularly heavy business job included seven 
sorts and! seven interspersed COBOL program runs. This job ran about 1 1/2 hours in 
total processing time. In addition to many COBOL business programs and FORTRAN 
student programs, some programs were included for the SN OB OL, ALGOL, MIX, 
and RPG languages. In total the mix was about 75% business data processing. 

The preliminary results, tabulated below, show UTS on the Sigma 9 to be an outstanding 
price-performer against major competition. 









Price 


Bench- 








Operating 


In 


Mark 


Bid Price, Adjust 


Firm 


Machine 


System 


51000 


Timemin. 


For Performance 


Xerox 


Sigma 9 


UTS 


2201 


165 


2201 


IBM 


370/155 


OS/MVT 


3209 


150 


3046 


CDC 


Cyber 73 (6500) 


Kronos 


3754 


105 


3068 


UNIVAC 


1106 


EXEC8 


3066 


? 


? 


Honeywell 


6070 


GECOSIII 


2966 


? 


? 



Benchmark results are not known for Univac and Honeywell, but according to the sales 
office in Dallas they also do not compete with UTS. Price includes machine maintenance, 
conversion, and software costs. The configuration benchmarked differs from the 
configuration bid in that current tapes and packs were used while new 1600 bpi tapes 
and disk A's will be delivered. Presumably these higher performance devices will 
increase the performance of UTS for this highly I/O-bound benchmark. 
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10.3 COBOL COMPILATIONS 

Recent carefully conducted tests run by the COBOL development group are reported in 
PDS3-72-236, dated August 3, 1972. They compare COBOL compilations under BPM, 
UTS, and XOS. The principal results for the six compilations which ranged in size 
from 500-10,000 cards are as follows: 

BPM 1178 cards/minute 

XOS 1817 cards/minute 

UTS 2055 cards/minute 

In addition to the 10 percent performance advantage of UTS over XOS, the study also 
shows the effects of the file allocation strategies of the two systems. Significantly 
higher temporary storage is required in XOS than in UTS. The effect is more pronounced 
for small compilations. The ratio of storage required ranges from 3.6 to 1.4. 

10.4 IMPROVEMENT BY UTS VERSION 

UTS has shown a steady increase in throughput capability for each new version. The 
table below summarizes this steady improvement. Features have been included in C01 
and are underway for D00 which will continue the established trend. All data are 
taken from the 128K Sigma 7F, are averages over periods of 3-10 days, and consist 
of the heavily loaded prime shift only. 
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A00 


29 


84 


3100 


25 


830 


A03 


24 


83 


3000 


24 


830 


B01 


27 


80 


4200 


27 


1100 


COO 


46 


76 


5600 


48 


1430 



Service provided by UTS has increased satisfactorily, particularly with COO as measured 
by (1) the number of users serviced, (2) CALs (monitor service requests), (3) terminal 
interactions, and (4) I/O rates per minute. The small cost in CPU utilization is not 
proportional to the work done, which reflects improvements in operating system 
efficiency. Most of the waiting time, which is for I/O, can be regained by use of 
larger memories and/or faster I/O devices provided for in D00. 
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11.0 STATISTICAL DATA 

11.1 ■ CONFIGURATION 

The minimum-cost configuration for UTS consists of the following: 

a. Sigma 6 CPU with map, memory protect, two interrupt levels, decimal and 
floating arithmetic, and one extra register block 

b. 64K words of core memory 

c. System and file RAD 

d. One 9-track tape 

e. Operator's console, card reader, and line printer 

f. COC gear and lines as necessary to the application 

The need for COC gear, extra register block, and interrupt levels may be eliminated 
if a batch-only system is desired. (A configuration of this sort has been ordered by 
Memphis State University for delivery this fall.) At minimum software cost, the COC 
routines may be removed from the resident monitor to release core for jobs. 

In the minimum-cost installation, more file storage is usually required than is available. 
In this case, the RAD may be replaced by a disk pack for combined system residence, 
swapping, and file storage. 

11.2 MONITORSIZES 

There are many ways to measure the "size" of a system. The following subsections 
provide several different breakdowns which describe the "size" of UTS; all of them 
relate to the parts of the system as maintained by the UTS Section except as noted. 

11.2.1 Source Code 



System source code (including comments) in compressed form for the COO version of 
UTS is contained in 283 files comprising 1.2 million words. 

11.2.2 Execution Form in the System Account 

The system account, :SYS, contains the ready-to-run load modules for the UTS 
system, all of the language and other processors, error logs, accounting files, 
authorization files, etc. In total much more than just UTS system modules are 
included. The system account for COO UTS on the Sigma 71 in EI Segundo contains 
1.6 million words in 175 files. 
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11.2. 3 Resident Monitor 

The UTS fixed resident monitor for the COO version of UTS ranges from 24. 5K to 32K 
words^ Improvements for D00 will result in a batch-only resident monitor of about 
22K words. 

11.3 RESTRICTIONS AND LIMITATIONS 

The attached appendix lists the current restrictions and limitations of UTS. Many of 
these limits are so wide as to constitute recommendations rather than limitations. 
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12. RELIABILITY AND AVAILABILITY 

12. 1 Memory Access Protection 

All programs are divided into procedure and data areas which are 
separately protected with execute-only and read/write access 
codes. Access codes and write locks together are used to protect 
users from one another, to protect the system code from the user, 
and to prevent the system from writing in its own procedure area. 

12. 2 Device Error Recovery and Reporting 

Error and fault detection, correction and reporting facilities 
provide for automatic re-try of device errors and machine faults. 
In the event of an uncorrectable error the effect is confined to 
a single user. Error log entries capture pertinent data to use in 
analyzing errors and in predicting problems by observing rising 
error rates. This technique has been used by Field Engineering 
to provide excellent up time on El Segundo on UTS machines. 

12. 3 Automatic Recovery 

System malfunctions resulting from either software or hardware 
problems cause automatic recovery and restart of the system. 
The process. closes all open files to preserve the most recent 
updates of each, updates accounting information, and provides 
a system dump for automatic analysis. Recovery takes one to 
three minutes depending on the current user load. On-line 
users are immediately notified by recovery of the interruption 
of service. Batch jobs in the queue waiting to run are preserved 
and run on restart. Output for completed jobs is preserved 
and printed. Lines remain connected and users are automatically 
provided with the logon sequence when the system is restored. 

12.4 Critical System Table Protection 

The granule allocation tables for the file system and symbiont 
queues are maintained on secondary storage. Even a complete 
loss of core memory does not affect file integrity. Re-booting 
from the system RAD recovers the critical tables without need 
for a costly file reconstruction process. A file reconstruction 
facility does exist; it can be activated at a convenient time to 
recover the small loss of unused granules recorded in the stacks 
at the time of loss core. 

12. 5 Consistency Checks. 

The operating system performs internal consistency checks 
throughout its operation. A complete user state/event matrix 
governs the scheduler's operation, thus insuring that 
inconsistent events are immediately detected and appropriate 
recovery initiated. The file management system is protected 
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by comprehensive fl ink/blink (forward and backward disk address 
links) checks which discover Tile system errors before they have a 
chance to propagate. The I/O system performs tests on the 
reasonableness of each I/O request, refusing to perform patently 
outrageous requests. Options are available to check-write each 
RAD or disk write operation as well as invoke a software read 
check on swap operations by including a unique "serial number" 
in each page written. Comprehensive tests are performed on all 
user requests to insure validity of the request and authorization. 
Near-absolute protection is provided against both accidental 
and malicious misuse of the system. 

12.6 File Backup 

The FILL processor backs up user files according to a schedule 
supplied by the installation or an explicit user request. Three 
levels of backup are provided by the SQUIRREL, INCREMENTAL, 
and SAVEALL functions. 

These three file saving modes provide for a hierarchy of file 
backup tapes which contain the most recently modified files. 

Saveall - saves all files in the system providing the basic 
backup point. 

Incremental - saves only files which have been modified since 
the last Incremental or Saveall. This consolidates the files 
saved by Squirrel onto a single tape so that the individual 
Squirrel tapes may be released. 

Squirrel - saves recently modified files for the most detailed 
form of file protection. Squirrels may be run each hour for 
especially high safety of the files. 

FILL also controls the purging of expired and, if necessary, 
inactive files insuring that the files are saved on tape prior 
to deletion in order to release file storage space. 

A media dump facility exists which saves all RAD and disk 
storage on tape by fast cylinder mode transfer. Only 
active tracks and cylinders are saved. A combination of 
the media dump tapes with FILL, squirrel and incremental 
tapes can be used to insure rapid recovery in the event of 
a complete file system loss. Media dump may also be used 
to create an exact copy of a private pack onto another pack. 

12.7 FAST SAVE/RESTORE. A device speed file save/restore 
facility is provided. The file system is copied to tape on 
a file by file basis thus providing for a selective restore 
and the ability to transfer to a different system. 
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12.8 Maturity and Field Experience 

UTS has two years of field experience, much of it in extremely 
demanding environments. Its roots are in BCM, RBM, BPM, 
and BTM so much of the code and the internal design has up 
to seven years of experience. 

UTS is currently installed in more than 25 locations: 19 are 
running it full-time production, 6 part-time, and 7 are to be 
installed in the next 90 days. UTS has many excellent 
reference accounts, and will have 30 to 50 sites in 1972. 

Seven new sales have been made this year because of UTS— 
4 Sigma 6s and 3 Sigma 9s. 



Page 34 



13. MAINTAINABILITY AND EXTENDABILI'i Y 

UTS Includes extensive and proven capabilities for maintaining itself both in 
El Segundo and in the field. Its features and facilities are powerful tools for 
extending its own capability. These features and facilities have been de- 
veloped through experience gained in development of UTS and its ancestors - 
BTM, BPM, RBM, and BCM - over the past seven years. Items of specific 
importance follow. 

13.1- ' SOFTWARE CHECKOUT AND REPAIR 

13.1.1 Automatic Crash Analysis 

Explicit internal tests detect most software and some hardware problems and 
activate the system recovery routines. A dump taken at this time is submitted 
to a ghost job that provides an analysis of the problem, including the immediate 
symptoms and formatted presentations of system tables and job-dependent informa- 
tion. About 20 specially formatted tables are presented in terms of well-known 
system symbols, permitting fast and accurate isolation of the problem either by 
home office experts or by field analysts. The analysis and repair of problems 
is thus especially prompt. 

13.1.2 Remote System Analysis 

The same routines used for automatic analysis may be used during system 
operation from any remote or local terminal to isolate system problems in a 
crash dump on file or in the running system itself. Further, the language DELTA 
may be used to examine and repair the running monitor, again from a remote 
terminal. This facility has proved especially valuable as a fast, money-saving 
aid to solving problems at several UTS Installations; it allows several home 
office experts to combine their various talents to solve a problem within hours 
rather than making long, expensive trips to the customer's site. McDonnell 
Automation, DREV, Memphis State University, NYIT, Bucknell, and others 
have been helped with remote techniques. In these cases our people in the 
home office have logged onto the customer's system, gathered information, 
analyzed it, and dynamically applied the correcting patch. 

13.1.3 Executive DELTA 



For especially difficult problems which require hands-on control, the executive 
debugger, XDELTA, provides for complete total control of the operating system. 
Breakpoints may be set to stop the system for examination at crucial points using 
the symbols of the system for accurate, easy-to-read displays. 



13.1.4 Symbolic Patching 



XDELTA is also used to patch the system at boot time. The same symbolic patch 
format is used for both debugging and for patching. Patches are generally re- 
locatable so that patch decks may be applied without change to all systems re- 
gardless of the SYSGEN configuration. 
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13.1.5 Boot-Under-the Files 

When it" is necessary to apply parches to a production system, UTS provides 
for rereading the patch deck without disturbing the permanent files of the 
system and its users, which avoids the necessity of saving and restoring an 
extensive file system in order to apply critically needed patches. 

13.2 HARDWARE CHECKOUT AND REPAIR 

13.2.1 Error Log 

UTS provides a log of all recovered hardware errors as well as unrecoverable 
faults. Analyses of this log have consistently provided Field Engineering 
personnel with a prediction of faults through increasing error rates. Thus they 
are able to repair devices in nonprime time, before the device becomes 
unusable. 

13.2.2 On-Line Diagnostics 

Within the system, diagnostics are provided that may be used from either local or 
remote terminals to analyze and repair card readers, card punches, line printers, 
magnetic tapes, RADs, and disk packs. These run during system operation 
without disturbing on-line users or batch fob throughput (except, of course, 
for jobs requiring the down device). Full direct access to the device is pro- 
vided, and all hardware status information - TDV, TIO, AIO - for the read 
or write operation is returned to the diagnostic. 

13.3 DOCUMENTATION 

Use and maintenance of UTS is supported by the following documentation. 
Five user manuals relate directly to the use of UTS: 

"Batch Processing Reference v 90 17 64 (203 pages) 

Time Sharing Reference 90 09 07 (135 pages) 

System Management Guide 90 16 74 (236 pages) 

Operator's Manual 90 16 75 ( 49 pages) 

User's Guide 90 16 92 (107 pages) 

Five other user manuals relate to operations under UTS of language processors: 

BASIC Operations Manual 90 15 46 

Metasymbol Operations Manual 90 09 52 

FORTRAN Operations Manual 90 11 43 

FORTRAN Debug Reference 90 16 77 

COBOL Operations Manual 90 15 01 
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UTS Internals are extensively and completely documented in the following 
software technical manuals: 

UTS Technical Manual 703029 (2500 pages) 

BPM Technical Manual 90 15 28 ( 350 pages) 

(for Compatible Items) 

Overlay Loader Tech. Manual 90 18 03 ( 122 pages) 

SYSGEN Technical Manual 90 18 77 ( 321 pages) 

DELTA Technical Manual 90 18 79 ( 39 pages) 

EDIT Technical Manual 90 19 11 ( 105 pages) 

PGL Technical Manual 703027 ( 100 pages) 

13.4 DEVELOPMENT AND TEST 

Several programs and procedures facilitate the development of new versions 
of UTS, including the required extensive regression testing. 

a. On-line SYSGEN: provides for quick, accurate and convenient 
production of new systems for regression test. 

b. DRSP: provides for the replacement of shared processors with new 
versions without need for SYSGEN. 

c. System simulators: portions of the operating system are isolated for 
test under simulators and thus may be debugged from on-line 
terminals. UTS file management and Terminal I/O routines are 
checked out in this manner. 

The C01 merge of ANS tapes (3000 lines), 120 SIDRs, and other 
C01 development, a total of 1000 lines, was brought up 
within one week to the point of successfully running running re- 
gression tests. The reason was that ANS code had been thoroughly 
checked out in simulation on-line on the production Sigma 7T. 

cL Listing library: a centralized listing library provides accurate, 

complete, and available documents for analysis of each version 
of the system. 

e. Centralized definitions: certain system-wide definitions are carried 
in common packages (DATADEF-like) provided for accurate reference 
from any module. 

f. Automatic regression testing: the program QUAC makes it possible to 
submit the entire regression test library automatically. 

g. TTS: the Sigma 3 timesharing simulator and the library of UTS test 
cases allow fast easy regression testing of the on-line services. 
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h. UPDATE: a program which merges and compares update packages 

for a given module to facilitate integration of separate develop- 
ment efforts. 

i. CROSSREF: a program which provides a complete cross-reference 

of all symbols used in the monitor, showing where it is defined and 
all the places it is referenced. 

13.5 EXAMPLES OF EXTENDABILITY 

UTS has shown an accelerating development pattern over the last year and a 
half. It becomes easier and easier to add new features to the system. Two 
factors are probably responsible for this: first, the solid fundamental design 
of the system. Much long range planning was done in the early days. 
Second, for the last year and a half the system has been solid enough to 
support its own continued development, becoming an important tool in the 
development process. 

Several recent features are examples of system extensions which required an 
unusually short development time. 

Most features specified for X MS are in the current system; 
they were put in place with disarming ease. 

Major enhancement to remote batch support went into the 
system smoothly, release COO was ready ahead of schedule. 

The general command processor interface for EASY was added 
to the system with only one and a half months of effort. 

Exit control has been designed, coded; and is ready to go 
into the system at a cost of one and a half man/months. 

The system features which have made this possible are the modular division 
of the monitor by function, the simplicity of the interfaces between functional 
modules and the generalized functions performed by the memory management, 
execution scheduler, and the swapper. These same hooks allow and facilitate 
a number of natural extensions to UTS. 

Interprogram communication - by making use of existing event- 
reporting logic in the execution scheduler, it is possible to write 
two new CALs which permit message transfer from one program to 
another. 

Transaction processing - the combination of exit control, interprogram 
communication, and the shared processor feature of UTS provides very 
naturally for the generation of transaction processing applications. 
These applications can be based as well on keyed files or on DMS 
random files. 
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Demand paging - the potential addition of demand paging to UTS 
is facilitated by the existing swapper and memory management 
code. This existing code would require minimal change. An 
enhanced trap handler to detect and analyze page faults and 
alter the swap or working set through existing memory management 
facilities is the only new code required. While permitting large 
(virtual size greater than physical size) users to execute, this 
approach retains the efficiency of UTS swapping for small users. 
The modularity of UTS would permit even demand paging to be 
a SYSGEN option. 
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14. 



AVAILABLE LANGUAGE AND APPLICATION PROCESSORS 



14.1 



CLASS Al PROCESSORS 



Manage 



CIRC-DC 



DMS 



CIRC-AC 



SL-1 



GPDS 



C.IRC-TRANSIENT 



Generalized file management system including 
update, retrieval, and report generation. 
Terminal-oriented Manage (TOM) is available 
for on-line use. 

DC circuit analysis. Batch or on-line. 

Generalized data management system. Batch 
or on-line. 

Provides frequency domain analysis of 
electronic circuits. 

Real-time hybrid continuous system simu- 
lation language. 

General purpose discrete simulator. Batch 
or on-line. 

General purpose time-domain analysis or 
electronic circuits. Batch or on-line. 
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CLASS Bl PROCESSORS 



META- SYMBOL 



SORT /MERGE 



1400 SIMULATOR 



BASIC 



Meta-assembler . Batch or on-line. 

Generalized file sorting and merging. 

Used to execute 1400 series object programs 

Interactive algebraic compiler. Batch or 
on-line. 



EXTENDED XDS FORTRAN IV FORTRAN compiler and libraries. 
ANS COBOL COBOL compiler. Batch or on-line. 
TEXT ATS-like on-line document processing system. 

APL Interactive functional programming language. 



EASY 



The GE MARK I I- like system for BASIC and 
FORTRAN. 
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15. FUTURE COMMITTED FEATURES 



This section lists only those features which are explicitly 
committed for development by marketing announcement or approved 
field request. Many other enhancements are feasible in UTS 
and have received some design attention. 

15.1 OCP, 2Q73. Support for the XEROX Optical Character Printer 
as a symbiont device. 

15.2 IRBT, 2Q73. 

IBM HASP multileaving, record compression/decompression 

IBM Bi Sync communication protocol 

2780 support 

Facility for computer-to-computer communication between 

UTS systems 
Multiple peripherals at remote stations 
Forms control at IRBT 
Support for remote operator consoles 

Flexible control over the priority of input and output files 
Multiple copies and routing of copies to remote terminals 
Comprehensive backup control over printed output 
Workstation accounting 

15.3 NO-WAIT 'I/O, 2Q73. No-wait I/O will provide substantial 
performance improvements for many applications . The support 
will include automatic double buffering and I/O independent 
of the user. That is the user may swap while his I/O is in 
progress. 

15.4 1600 BPI TAPE, 2Q73. 1600 BPI tape support will include 
resource control for mixed density systems. 

15.5 TAURUS, 1Q74. 

15.6 RMA, 4Q72— >-4Q73. On-going improvements for RMA are scheduled 
through the fourth quarter of 1973. Improved error logging, 
error analysis, and on-line diagnostic support will be provided. 
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16. SPECIAL FEATURES 

16.1 COMPATIBILITY WITH BPM/BTM 

UTS is entirely compatible with BPM/BTM. Files are trans- 
ferable, programs are executable, and the terminal protocol 
is, for practical purposes, identical. This means that UTS 
can run without change not only all processors developed for 
BPM/BTM, but also programs from the comprehensive user group 
Library, which includes SNOBOL, LISP, APT3, ADAPT, MIX, SOL, 
ALGOL, ECAP, FLOPLOT, and other programs listed in Section 
14. 

The 32K BTM system provides UTS with its low entry system. 
Compatibility provides for upgrade to UTS without conversion, 
The process has been accomplished in a matter of a few hours 
or a few days. 

16-2 SHARED PROCESSORS 

The procedure portion of most processors, libraries, and 
monitor overlays is shared among all concurrent users . 
For example , if four FORTRAN coded programs are running 
concurrently, only one copy of the library is required. 
This yields a savings of 13. 5K words — enough core to run 
another job. About 40 processors and overlays are shared 
in UTS, which results in particularly efficient uses of 
core memory. Using DRSP, these shared processors may be 
replaced during system operation with updated versions 
without disturbing on-going work. Current users of the 
replaced processors continue to use the old version 
until they terminate. Installations may take advantage 
of this core-efficient facility by adding their commonly 
used processors and libraries to the system as shared 
processors either at SYSGEN or dynamically, via DRSP. 

16-3 FACILITIES FOR INSTALLATION DEVELOPED COMMAND, PROCESSORS 

(SUB-EXECUTIVES) 

UTS provides in its standard release the batch command 
processor, CCI, the general-purpose terminal command 
processor, TEL, and the special-purpose GE MARK II- like 
command processor, EASY. Installations, may use the 
facilities provided for these processors to develop 
their own command processors (also called "sub-executives") 
to satisfy special needs. A command processor is a shared 
processor that is given control on all exits, errors, 
aborts, breaks, and hang up conditions resulting from 
programs executing under its control. When coupled with 
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the SUPER specified auto-call-at-log-on facility, it can 
therefore provide an isolated environment for a particular 
class of users that may be separately charged for the 
restricted services provided. If desired, one command 
processor may pass control to another, thereby granting 
a greater range of service up to the full set of system 
services. 



16.4 GHOST JOBS 



Ghost jobs are independent tasks which, rather than entering 
the system through a card reader or on-line terminal, are 
initiated at program request by the operator, the system, 
or by a current job. Many system tasks (e.g., crash analysis, 
performance monitoring, secondary storage allocation, multi- 
batch scheduling, remote batch support, and system initial- 
ization) take this easy-to-add and easy-to-maintain form and 
thus do not add to the resident or nonresident system overhead, 
Any program may be called as a ghost job for the specific 
needs of a particular installation. Ghost jobs form a 
"parallel" class of jobs which may be called into execution 
by the operator. Newport News, for example, runs a subset 
of the CPU diagnostics via a ghost job during lightly loaded 
periods. The number of ghost jobs allowed in execution 
at any one time is a SYSGEN parameter. 

16.5 CENTRALIZED UTILITIES 

A single comprehensive processor (PCL) that may be used in 
either batch or on-line environments replaces the usual 
proliferation of utility programs. Transfer of files in 
any system format is accomplished between any two devices 
via an easy-to-use command language. Format conversion 
and record selection may be specified for the transfer 
and files may be concatenated or split. 

16.6 ! VIRTUAL MEMORY MANAGEMENT AND SWAPPING 

This important UTS facility is discussed in Section 1. 

16.7 ON-LINE BATCH COMPATIBILITY 

This is also discussed in Section 1. 
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UTS OPERATIONAL RESTRICTIONS 
AND LIMITATIONS 



1. File System 

2. DCBs 

3. Assignments and Sets for DCBs 

4. Symbionts and Cooperatives 

5. Physical Core 

6. Virtual Core 

7. Lines, Jobs, and Users 

8. Devices 

9. Terminal I/O 
10. Other 
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1. File System 

a. File names are limited to 31 characters, except for: 

1. Names supplied via TEL where the limit is 
ten characters. 

2. ROM names which are limited to ten chars. 

b. The number of accounts allowed is limited by requiring 

ibl 
11 



o 
a printable name of eight characters or about 40 . 



264 x 10 

c. The number of files per account is limited by requiring 

31 
expression in 31 characters which is greater than 40 

d. The size of a keyed-file record Key (name) must be 
< 31 characters. 

e. The maximum number of records per keyed file is greater 
than40 31 . 

f. The number of records in a consecutive file on RAD 

31 
must be less than 2 

g. There can be no more than seven levels in a keyed file 
multi-level index. (Implies a limit of more than 22*57 
records.) 

h. No public file may total more than 32767 granules, a/16 x 10 

i. No private pack file may exceed 65535 granules 

(somewhat less than six packs). 

j. There can be no more than 399 files per private pack. 

k« The minimum allocation unit for private pack files is 
30 granules. 

I. The size of records in a file is limited by the requirement 

that the record be entirely contained in core memory when 
written. 
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2. DCBs 

a. Length of an individual DCB is limited to 255 words. 

b. The number of DCBs is limited by the rule that the total 
space for DCBs and buffer pools (POOL command) may 

not exceed 11K words. Individual DCBs must not overlap page 
boundaries - this is enforced by the Loader so some 
"breakage" space results in packing of DCBs into memory. 

c. The DCBs M:UC, M:OC, and M:XX do not require space 
in the DCB area. An M:DO DCB is always supplied by 
LINK; LOAD supplies and M:DO DCB except when NOTCB 
is specified. 

d. If an M.-PRINT CAL is used, then an M:LL DCB is generated 
and included in the DCB area. If the program LOAD speci- 
fies SEG, REF, or BREF, then an MrSEGLD DCB is supplied 
through which the overlay I/O is accomplished. 

e. For LINK loaded programs only a limit of two pages of DCBs 
'"'•applies.' 
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3. ASSIGN and SET Commands for DCBs 

a. Total number of active SET commands is limited to 12. 
Unneeded SETs may be removed with a SET DCB com- 
mand. 

b. Total number of ASSIGN commands is limited by the 
size of the associated FPTs (sizes as if M:OPENs had 
been issued for the ASSIGN information). Total size 
of FPTs may not exceed 490 words or about 40 ASSIGN 
commands (12 words for a typical entry). 

c. Serial numbers for tapes and private packs are limited 
to four characters. 

4. Symbionts and COOPeratives 

a. A maximum of three COOP devices may be open at any 
one time during program execution. 

b. The number of symbiont input and output files is limited 
only by resident memory size. Two words per output file 
and 6-3/4 words per input file. The resident memory re- 
quirement for input files is lifted in a 2Q72 UTS release. 

c. Space for symbiont input and output files is taken from the 
sysgen set values but PFA granules are used if PER is entirely 
used. 
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5. Physical Core 

a. Total memory allowed is 128K for Sigma 6/7; 
memory to 512K is allowed on Sigma 9 with a 
later UTS release (4Q72). 

b. The resident monitor may not exceed 32K (to 
the beginning of the module JIT). 

c. No monitor overlay may exceed 3K. 

d. Minimum memory is64K. 

e. Minimum resident monitor is about 24K. 



6. Virtual Core 

av No program may exceed 63.5K (extended to 76K in 
4Q72), including program, data, DCBs, and buffers 
but excluding associated shared processors. 

b. The minimum requirement for DCBs and buffers is 
1.-5K. 

c. No special shared processor can exceed T6K. 

d. Combined size of DCBs and buffer pools may not 
exceed 1 1 K. 
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7. Lines, Jobs, and Users 

a. The total number of concurrent active jobs (users) 
in UTS (batch plus on-line plus ghost) may not 
exceed 255. 

b. The total number of terminal lines connected to 

a UTS system may not exceed 512 (7611 hardware 
limit). 



8. Devices 



a. The total number of I/O devices - tapes, packs, RADs, 
card readers and punches, line printers, 761 l's, 7601 ! s, 
plotters, paper tape readers and punches, etc., - 

may not exceed 255. 

b. The minimum configuration requires line printer, card 
reader, 7232, 761 1, and operator's console. 

c. The total number of packs plus tapes may not exceed 
32. 

d. The largest record that may be written to a device 
(as distinguished from monitor-managed files) is 
32K-1 bytes. 
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9. Terminal I/O 

a. An individual M:READ or M:WRITE may not specify 
more than 140 characters of length. 



10. Other 



a. A FILL SAVEALL must be contained on eight tape reels 
(36 in a later release). 

b. There can be no more than 255 CFUs. 

c. A SNAP may not specify more than 255 linked FPTs. . _ 



